home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5482 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.9 KB  |  110 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.sprintlink.net!eskimo!scs
  3. From: scs@eskimo.com (Steve Summit)
  4. Subject: Re: void main() and other atrocities!
  5. X-Nntp-Posting-Host: eskimo.com
  6. Message-ID: <DMHCyB.C7y@eskimo.com>
  7. Sender: news@eskimo.com (News User Id)
  8. Organization: schmorganization
  9. References: <4erjn2INN38b@keats.ugrad.cs.ubc.ca> <9602021300.AA04359@dxmint.cern.ch> <4f2rahINNmud@keats.ugrad.cs.ubc.ca>
  10. Date: Thu, 8 Feb 1996 23:22:58 GMT
  11.  
  12. In article <4f2rahINNmud@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
  13. (Kazimir Kylheku) writes:
  14. > I know that it would break a compiler that generates an incompatible
  15. > linkage for functions returning int and void functions (assuming that
  16. > the function you are calling does not return). But I just don't know
  17. > of any that do (and it would be silly to write one that generates
  18. > subroutine linkage code which breaks when a void function is called
  19. > that is assumed to be int).
  20.  
  21. Why would it be silly?  The only reason for going out of your way
  22. to make void- and int-valued functions compatible would be to
  23. coddle the large body of existing C code that mistakenly assumes
  24. that they are.  (This is, to be sure, a big reason.)  If, on the
  25. other hand, you could get away with making void- and int-valued
  26. functions incompatible, you could, for example, make it easier to
  27. mix C functions with Pascal procedures and functions, without
  28. requiring klunky nonstandard "pascal" keywords.  (This issue is
  29. of more than academic interest when you're doing any Macintosh
  30. programming.)
  31.  
  32. > It's also atrocious that main() has to be treated as a special
  33. > language construct,
  34.  
  35. But it doesn't.  Many compilers do special-case main(), and it's
  36. not out of the question since it's such a distinguished function,
  37. but the only way the C Standard might force a compiler to special-
  38. case main() is that it has two acceptable prototypes (which is a
  39. terrible anomaly).
  40.  
  41. > and that a call to exit() in main() (when it is
  42. > the last statement) is to be identical to a return.
  43.  
  44. Huh?  What's so atrocious about that?  (And why are you arguing
  45. so strongly for atrocity here, when you're so moderate in your
  46. next sentence about how serious a mistake void main() is?)
  47.  
  48. > I don't advocate that people declare main() to return void (in fact I
  49. > don't do so myself), 
  50.  
  51. Good!  But why condone or make excuses for the practice?
  52.  
  53. In fact, let me ask this: to anyone who vociferously argues that
  54. there's nothing wrong with void() main, what's right with it?
  55. What's so wrong with int main() that you refuse to use it?
  56. Why are you so determined to use void main()?
  57.  
  58. > but I don't see it as some sort of big mistake.
  59.  
  60. It's true that people on comp.lang.c tend to make an overly big
  61. deal out of it.  It's true that it's likely to work in a large
  62. number of situations.  But it's also true that there's no good
  63. reason for using it (well, I take that back, I guess it's only my
  64. opinion that there's no good reason for using it), so I don't
  65. understand why the argument persists.
  66.  
  67. > I did read the relevant section in the FAQ. It is merely concerned
  68. > with the issue of eliminating compiler warnings stemming from calling
  69. > exit() in main() despite a "void" declaration thereof.
  70.  
  71. Well, that's what the question was originally concerned with,
  72. anyway; back when I composed that entry, void main() was rare and
  73. was done for a deliberate reason (to eliminate warnings when
  74. main() called exit() and did not explicitly return).  But now --
  75. as proliferating numbers of programmers seem to be using the
  76. silly little construct, not knowing why, but merely basing their
  77. habits on the proliferating numbers of books which use the silly
  78. little construct, and arguing, in spite of the fact that they
  79. don't know what they're talking about, that since their books use
  80. it it must be okay, and suggesting that the pedants on
  81. comp.lang.c must not know what *they're* talking about -- now,
  82. that question has definitely shifted its focus, as evidenced by
  83. its three follow-on questions.
  84.  
  85. > The issue that
  86. > a void function may not be compatible with a call to an int function
  87. > doesn't seem that significant, since nobody in their right mind would
  88. > design a compiler that way.
  89.  
  90. Saying that "nobody in their right mind would design a compiler
  91. that way" is a pretty weak argument.  Saying that "the C Standard
  92. allows a compiler to be designed that way," with the inference
  93. that portable code ought therefore to allow for the possibility,
  94. is a much stronger argument.
  95.  
  96. > There is something magical about the old-style C that attracts me. I
  97. > can't quite put my finger on it...  Can someone else identify with me? :)
  98.  
  99. Well, I certainly prefer K&R C to ANSI C; I have no use for
  100. function prototypes (or for void functions, for that matter).
  101. But ANSI/ISO C is unquestionably modern practice; it's what I
  102. teach in my classes; it's what I've tried to migrate the FAQ list
  103. to concentrate on; it's what we mostly talk about here; it's what
  104. most C programmers should be programming in.
  105.  
  106.                     Steve Summit
  107.                     scs@eskimo.com
  108.  
  109. February 8, 1996: A dark day for the net
  110.